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Abstract-A true VoD system has tremendous demand in the 
market. The existing VoD system does not cater the needs 
and demands of the market. The major problem in the VoD 
system is serving of clients with expected QoS is difficult. In 
this paper, we proposed a protocol and algorithm that 
chains the proxy servers and subscribed clients. Our 
objective is to send one server stream and this stream should 
be served to N asynchronous clients. The server bandwidth 
is scarcity and on the client uplink bandwidth is 
underutilized. In this protocol, we are using client's residual 
bandwidth such that the load on the server bandwidth is 
reduced. We have proved that optimal utilization of the 
buffer and bandwidth for the entire VoD system and also 
less rejection ratio of the clients. 

Index Terms- Video-on-Demand (VoD), Quality of Service 
(QoS), Chaining, Segment, Bandwidth 



I. INTRODUCTION 

With internet reaching out to a global audience today, people 
are expecting and extracting a lot of new features and facilities 
from it, IPTV being one of them. IPTV provides a lot of 
features that conventional cable television fails to provide, such 
as high definition video quality and VCR functions like pause, 
fast forward, rewind, etc. Another important aspect that makes 
IPTV so popular and better than conventional cable television is 
Video on Demand (VoD). VoD involves, streaming video files 
from a remote server to the client systems on an individual 
basis. This involves streaming of videos requested by the clients 
specifically to them. This provides a certain kind of customized 
viewing option that is absent in regular cable TV. The client 
requests for a particular video on a VoD server and the request 
is processed and served by the server. 

Through VoD, the video can be viewed as it is being 
downloaded from the server. Along with this the VCR functions 
provide an extra edge over conventional television, letting the 
user decide when and how to watch the video. 

The implementation of VoD requires a high bandwidth 
network framework consisting of a server that has sufficient 
storage capacity to store video files. 

IPTV generally uses HDTV videos and hence the servers 
need to have large storage capacities to store the video files. 
This constitutes one of the main requirements of a VoD 
network. Using MPEG standards the bandwidth required is 
2133 Mbps. Maintaining such a high bandwidth requires a high 
bandwidth network. This makes the service expensive and 
impractical to implement from the client's side. To overcome 
these drawbacks the network is implemented in three levels. 



• Level I has the main server with an optic fibre channel having 
a bandwidth in the range of 2 Gbps. 

• Level 11 has a cluster of proxy servers that are connected to 

the server at one end and to the clients at the other end. The 
connection on the server side is an optic fibre channel and that 
on the client side is a low bandwidth network that provides a 
bandwidth of 2 Mbps. 

• Level III has the set of clients that are served by the proxy and 
in turn by the server. 

When the client requests for a video from the proxy that 
serves the client. This proxy in turn requests the server for the 
particular video. The server then streams the video to the proxy 
and this is further streamed to the client. 

Whenever a video that is already being streamed to some 
client is requested the server streams it again, thereby streaming 
the same video to different clients and using twice the 
bandwidth for the same video file. The server bandwidth is of 
great importance in the network and the streaming of the same 
video twice hinders the optimal utilisation of the server 
bandwidth. On the other hand the uplink bandwidth on the 
clients' side is under-utilised. Providing a protocol for the 
optimal streaming of the videos using the clients' residual 
(uplink) bandwidth and hence reducing the load on the client 
constitutes our objective in this paper. 

n. REVIEW OF LITERATURE 

The VOD streaming has attracted quite a few researchers; 
some of the previous works have been reviewed here. There 
have been two kinds of works in this regard. They are: 

>* Building of Streaming servers 
> Protocol and architecture related works 
Since we are proposing a protocol we intend to concentrate 
more on the Protocol and Architecture related works. There 
have been quite a few innovative techniques and protocols 
proposed in this field. In prefix caching [2] concentrates more 
on the storage problems related to proxy servers, but in the 
current era where memory is cheap and easily available the 
significance of prefix caching lessens. 

In optimized distributed delivery [3] method a single 
multimedia file is split up and sent in parts from different 
servers. Effectively this is like multiple servers serving multiple 
clients. The drawback in this system is that it is very expensive 
to maintain multiple servers and the server bandwidth is of great 
value. 

In hybrid model [4] uses multiple clients called peers - lend 
or contribute their resources to the network and serve their 
peers. The model optimally uses all the network resources and 
provides very good service but the major drawback is that the 
model is too complex to implement. The protocol requires the 
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service of each and every peer and hence the service becomes 
less reliable. The protocol proposed in this paper overcomes all 
the drawbacks and limitations of the above mentioned 
protocols. 

III. SYSTEM ARCHITECTURE 

The structure of the network assumed in our protocol is as 
shown in Fig. 1. The network architecture consists of a Main 
Server at the top of the hierarchy. This is followed by a cluster 
of Proxy servers that act as an interface between the clients and 
the Server. Each Proxy can be thought of as a regional server 
that serves a set of clients that belong to a particular region. One 
of the aspects of having proxy servers is that the probability of 
two clients requesting the same video is more in a given region. 
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Fig. 1 : Network architecture 
At the same time, the more popular the video, the more the 
probability of a client requesting the same video. Hence the 
number of clients requesting for the video will be more. Thus if 
the Server satisfies each and every request for the same video, 
the server bandwidth is not optimally utilised. In order to avoid 
this, these popular videos may be stored in the Proxy buffer and 
streamed as and when the client requests for it. Since the 
popularity is region dependent, each proxy buffer contains the 
videos that are popular in a given region and the videos can be 
streamed directly. 

The videos are stored dynamically, that is if the popularity of 
a particular video drops, the video is automatically deleted from 
the proxy buffer giving way to some other more popular video. 
The popularity is based on the number of hits that occur for a 
particular video. The above mentioned parameters constitute the 
essential requirements for the proposed protocol. 

The optimal utilisation of the server bandwidth is 
implemented using "Chaining". When a video is requested by a 
client, the request is redirected to another client who already 
contains the same video in its buffer, instead of being served by 
the server or the proxy. This process is called "Chaining". This 
reduces the load on the proxy and, the main server. 
A. Proposed Protocol 
Fig. 2 shows the protocol followed in this implementation. 
When a connection is established between the client and the 
server, the client sends a "HELO" message to the server. When 
the server receives this "HELO" message, it requests the client 
for the "MovielD". In response the client sends the Movie ID to 
the server. On receiving the Movie ID, the server sends a 
"REDY" message to the client and waits for client's response. 
The client sends an "OK" message to the server indicating that 
it is ready to receive the movie. Once the server receives the 
"OK" message the server starts streaming the movie, segment 
by segment. For each segment the client receives, it sends an 
acknowledgement ("OK" message) to the server. The server 
sends the next segment only after receiving an 
acknowledgement from the client. 

To illustrate, when the proxy-server is streaming a movie to 
Client-i, suppose Client-j requests for the same movie, then the 
request of Client-j is forwarded to Client-i. Now the Client-i 
uses its up-link bandwidth to stream the same movie to Client-j, 
thus taking the load off the server. 
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B. Algorithm 

The algorithms that are required to implement the above 
protocol are as follows: 

CHAINING ALGORITHM 
Nomenclature: 

C= {C 1; C 2 , C 3 , C 4 C m }, Active clients 

P= (Pi, P 2 , P3, P4 PJ, Active Proxies 

Q->Client address 

P, -> Proxy address 

B, ->Buffer size used in client Q 

b= {(/Ji, #1), (M2, #2)- (H\, #i)}, b is a list containing /^and #, 

where n, is Movield , i9, is popularity 

D (ij -}->Distance between Client C,and C,- 

H^ Movield (Request Id) 

7i-> Uplink of client C, 

R = { r i, r i, r 3 r k}/ A list containing current streaming request. 

Bi-> Proxy P,'s current Bandwidth 

0->Maximum allowable buffer size of proxy P 

S r -> Requested segment 

S,-> Segment number i 

Q->A circular queue in client holding received segments 

Proxy 

Upon receiving request from client Q 

1 if /j in Rthen 

2 find j such that (cost[i) -> D (u) / ij{) < 

D {i pj/Bi, where r^n 

3 if 3 some j such that C,e C 

4 chain client C, to Cj 
5 i?; ->#i+l, where r,-> n 
6 else 
7 if 11 inb then 
8 initiate new stream r, to client Cj, 
R=R U {r,} 
9 i?i ->i?i+l, where r,^ n 
10 else 

11 send request r k -> \i to server 

12 receive segments from server 

13 if maxsize{b} > 6 
14 replace (/i k , i9 k ) in b with (//|, i?i) 
where i? k < t?j V j 
The above mentioned algorithm is the proxy server 
algorithm. The Proxy server waits for movie requests from the 
clients. Whenever a request is received, the proxy checks if the 
movie requested is being streamed to any client. 

If so the "cost of chaining" is calculated and compared with 
that of streaming without chaining and the most economical 
method is chosen. If Chaining is feasible then the client is 
redirected to the client that has the same video in its buffer. In 
case chaining is not a feasible option then proxy buffer is 
checked for the movie requested. If found the movie is 
transmitted by allocating a new stream to the client. In case the 
movie is not found in the proxy buffer, the request is redirected 
to the main server. 

The client requests for a video from the proxy server. If the 
proxy is ready to stream, the client receives an 
acknowledgement "SIG_READY" message. Then the movie is 
streamed from the proxy, segment by segment, to the client. In 
case the movie is being streamed to some other client, the 
address of that client is sent from the proxy in the 
"SIG_CHAlNTO" message, and the stream is transmitted from 
the peer client. When a client receives a Movie ID and an 
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Figure 2: Protocol 
address from the proxy, then the client starts streaming the 
movie in its buffer to the address mentioned, thereby 
contributing to the chain. If the requested movie is not in the 
buffer then the request is simply rejected. 
Client 
Send a request r, to proxy Pj 
Upon receiving SIG_READY from P, 
1 Receive segment S from P i; Q= Q U {S } 
2 cptr=0,i=0 

3 if B,< size(Si) 

4 Q=Q-{S in } 

5 Q=QU{Si} 
6 cptr ->cptr+l 

Upon receiving SIG_CHAINTO 

7 If S r in Q 

8 stream the segments S r to S n 

9 else 

10 reject 

IV. SIMULATION AND RESULTS 

The following are the assumptions made in the simulation 
model: It consists of a single server, 5 proxy servers and 80 
clients. The server had 20 movies each of size 4.9 MB. The 
proxy buffer was large enough to hold 50% of the data on the 
server .i.e. effectively 10 movies. The server to proxy 
bandwidth is 2 Gbps and the proxy to client bandwidth is 
2Mbps. The uplink bandwidth of the client is 256kbps. 

The graph shown in Fig. 3 is the combined graph of 
"Number of clients' v/s Time" and the "Number of streams v/s 
Time". We can observe that as time increases the number of 
clients increase. But as the number clients increases we can 
observe that the number of streams increases initially and then 
decreases gradually. 
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Fig. 3: Number of clients and Number of Streams v/s time 

This is because the proxy or the server serves the clients only 
till all the popular videos have been cached in at least one place. 
Later on the videos are chained from these places. 

The graph in Fig. 4 shows the number of requests /streams 
with respect to time. In this case the requested video is very 
popular and hence with time the number of requests for the 
video is increased. We can observe that as the number of 
req uests increases, the number of active chains also increases . 
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Fig. 4: Number of streams VS time 

Initially the video is present in very few clients, who are 
scattered in different locations. Hence the more number of 
active chains have to be created in order to serve the requests. 
But as the requests are served, the number of clients that have 
the video will grow. Once more clients possess the video, the 
number of active chains gradually decreases. The same is the 
case with the streams allocated for the video in the server as 
shown in the graph. But the number of streams is always less 
than the number of active chains ( as seen in the graph, the no . 
of streams is always below the number of active chains ) 
because of the chaining. The chaining reduces the number of 
streams from the server and hence the server bandwidth is 
conserved. 




Fig. 5: Rejection ratio with time 

The graph in Fig.5 shows Rejection Ratio with respect to 
time. The rejection ratio is defined as the ratio of the number of 
rejected requests to the number of active chains. It represents 
the fact that the client requests are rejected even though there is 
a possibility of chaining. This happens because even though the 
chaining is possible the cost of chaining exceeds the actual cost 
of streaming. The ratio is around 0.9 initially since the 
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numberof clients possessing the video is small and scattered. 
But as the number of clients that possess the video increase the 
rejection ratio comes down rapidly as shown in the graph. We 
can observe that the bandwidth initially increases with time and 
then peaks at a point and then reduces gradually to some 
constant value. 

Initially the number of requests that arrive have to be served 
by the server itself because the number of clients that possess 
the video is small, as shown in the previous graph of the 
rejection ratio. 



bandwidth 
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Fig. 6: Bandwidth utilization with time 

But once the chaining process is activated the bandwidth 
used of the server is reduced and hence the burden on the server 
is reduce d to a great extent. 
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Fig. 7: Buffer utilization 

The buffer utilization graph shown in Fig. 7 shows the client 
buffer utilized. Without chaining we can observe that the buffer 
utilization is erratic and decreases drastically with time. But 
with chaining we can observe that the buffer utilization is 
initially high and then reaches the peak and then falls down 
gradually. The peak represents the peak of the chaining process. 
After the completion of the chaining and the after the video has 
been fully watched by the client the buffer utilization falls; this 
is the dip in the graph. 



involved in a chain, breaks, our algorithm does not provide a 
mechanism to overcome the drawback. 
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V. CONCLUSION 

In this paper we have proposed a protocol for optimal 
streaming using the chaining process and clients' residual 
bandwidth. Through simulation we have proved the advantages 
of using this protocol in the real world environment. The 
protocol uses the clients' uplink bandwidth, the server 
bandwidth is optimised and also the clients uplink bandwidth 
that was previously under used is well utilised. 

We intend to build on the current system and make some 
improvements to make the rejection ratio even lesser as future 
enhancements. This will include procedures that will consider 
the popularity and the cost of streaming, in order to dynamically 
maintain the videos in the proxy and the servers. The algorithms 
used in this protocol are not equipped to handle fault tolerance. 
In case the connection between any two clients, which are 
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